1. Field of the Invention
The present invention relates to a computer security system. More particularly, the invention concerns a real-time security system for monitoring and verifying identities of executable computer code.
2. Reference to Related Art
There exists a rapidly increasing need to protect personal computers in a network against attack/infection by malicious executable code. This is true for both businesses and individuals. All PCs connected through networks, be it LAN or WAN, “always on” Internet connections (e.g., cable modem, digital subscriber line (DSL) access and wireless access) or a dial up are potentially vulnerable. In the absence of protection, personal computers routinely face exploitation, information theft and data loss.
An executable code is usually contained within an executable files of an application (*.exe, *.dll, *.vxd, *.com, Java applets etc), although can also be contained within a data stream without identifiable file of origin. It is important to note that unless the user's personal computer runs an application with coding errors making it vulnerable for exploitation, or a gross error in configuration of the operating system, in order for a hacker to get unauthorized access to the computer he must deliver a malicious executable code to the user's PC and this code must be executed. This delivery and execution can, for example, be accomplished through the transmission of a malicious executable code attached to an e-mail. Another method of delivery requires downloading of a malicious code disguised as a legitimate executable code within a file. Additionally, a malicious code may be transferred via removable media (i.e., disk or CD). Malicious executable code can also be delivered within network's data stream without placing on a target computer a discrete malicious application.
Personal computer security comes down to knowing the identities of executable code running on a PC or in other words to executable code control. The essence of the executable code control mechanism of any security software is identity verification of executable code running on the user's computer. For maximum security, the identity of all executable code must be verified and deemed “good” or “bad” and no executable code should remain “unknown”.
The simplest example of executable code control is our decision about installation and running a program based on the information we can collect about the program from various media.
Currently, there are also several major groups of software providing one or another level of executable code identity verification: 1) antivirus programs, 2) personal firewalls, 3) authenticity certificates, and 4) positive identity verification systems with centralized consoles for enforcing application control over the network.
Executable code control software or a part of it must be installed on the end-user's PC. Regardless of the type of the executable code control mechanism used, all executable code control software must discriminate between benign and malicious executable code. This discrimination may be accomplished by matching certain characteristics (file name, file size, file checksum, patterns of behavior, etc.) of a potentially dangerous executable code against a database of known malicious executable code. Typically, the database is maintained on the end-user's PC and must be either manually or automatically intermittently updated by the user or, particularly in positive identity verification systems by an administrator. Also, as is the case with electronic signatures, the signature's authenticity can be verified.
Antivirus programs use a presumption-of-innocence approach toward an executable code: “an executable code is considered to be safe, unless proven to be malicious”. An antivirus program has a database of electronic signatures (fingerprints) of known malicious executable code. Each executable code on a local computer is matched against each entry in a local database. The matching process may also include heuristic analysis and the analysis of patterns of behavior. If a match is found, an antivirus program will prevent the code in question from being executed.
The weakness of all antivirus software is that it only recognizes those malicious executable codes that are a part of its database. Any executable code that is not in the database will be considered to be “good”, be it malicious or not. It is not uncommon that hundreds of thousands of users are affected before a new malicious executable code becomes known to antivirus experts, added to the database and downloaded to users' computers. Also, each user must maintain on his/her computer the entire database containing hundreds of thousands of signatures or more, even though throughout the PC's lifetime fewer than ten signatures will be actually utilized. Transfer of databases to millions of users consumes vast resources in terms of traffic and time. In addition, there is a significant lag between the identification of a new malicious executable code and the distribution of a corresponding database update to the public. During this lag, it is very likely that the new malicious executable code will cause significant damage. Well-known examples of this phenomenon are the well-reported “Melissa” and “I Love You” programs that wreaked havoc before any effective antivirus software was available to the public. Indeed, it is current practice that whenever information regarding a new malicious executable code becomes available, that information must be downloaded and incorporated in a database on each PC. Updating such a database takes time, resources and often annoys the user. Also, an antivirus program has a relatively high response threshold. Typically, malicious executable code should cause some “symptoms” and exist in multiple copies in order to be detected. If a malicious executable code is not a virus, but a Trojan horse, that has no “symptoms”, was created for a specific attack, and exists in a very small number of copies, chances are that an antivirus company will never find it.
Personal firewalls approach executable codes control differently. They typically don't have a pre-configured local database and in theory may help the user to find a malicious executable codes that would not be known to an antivirus program, provided that the executable codes in question will be attempting to send or receive data over the network. Presently, there are several major commercial brands of firewalls for PCs (McAffee, Symantec, ZoneAlarm, etc.) and numerous smaller brands. The common feature of all these PC firewalls is the ability to intercept a request by an executable codes for sending/receiving data over the network. Any executable codes attempting to send or receive data over the network will initially be treated by a personal firewall as potentially dangerous. A firewall will typically report to the user the name of the application containing executable code trying to send or receive data and the path to the corresponding *.exe file. It will then wait for the user to determine/decide whether the executable codes is safe or not.
There are several problems with this approach to executable codes control. The most important problem is that the level of the user's expertise ultimately determines personal firewall effectiveness. Also, it is not reliable as a malicious executable codes may masquerade as a legitimate one, tricking the user into making a mistaken decision. Also, an increasing number of network enabled applications and the necessity to control those applications at the level of individual executable codes (*.dll, *.ocx, *vxd, etc.) brings the number of executable codes requiring identity verification up to hundreds. Not even an expert user, let alone an average user, is able to verify the identity (authenticate) of hundreds of ever-changing (due to updates) executable codes. As a result, personal firewalls typically limiting executable codes control to a to that of contained within *.exe files.
Unlike an antivirus program, positive identity enforcement systems treat any executable code that is not on the list of approved executable codes as “guilty”, be it malicious or legitimate. Coupled with a centralized management console it may provide higher security than an antivirus program or a personal firewall. Through the central application enforcement console each PC is connected to the central server. An administrator at the central server creates a set of rules (the rules may include, for instance, unique signatures of allowed applications containing executable code) for each PC. The rules are then transferred to each PC and will govern its use including allowing only approved (allowed) executable code to perform certain actions, for instance send or receive data over the network. Because any executable code that is not pre-approved will be automatically prevented from working (whether it is new, unknown or known malicious or non-malicious), the system is provided with a high level of security regardless of the user's expertise.
The centralized application enforcement console has still several serious drawbacks. First, it makes it necessary to continuously transfer updates of signatures of allowed (pre-approved) executable code to all PCs. In a self-confined, restricted environment of a single enterprise, when the number of allowed executable code is small, it might be practical. However, when there is a need to pre-approve all existing executable code for opened network users (or LAN users who require significant freedom of choice of applications by the end-user), the centralized enforcement console becomes ineffectual. It would require continual transfer of an immense database containing signatures of legitimate executable code, identities of which have been verified. Also, existing central management consoles would usually only control executable code contained within *.exe files. This is because the console administrator would typically not be able to verify identities of hundreds of executable codes contained in other types of executable files on his/her own.
Digital certificates represent another attempt to help the user in verifying identities of executable code. Such a certificate can be purchased by a software manufacturer from several sources (Thawte, Verisign and others) and utilized to digitally sign the files containing executable code, so that the end user looking at the signature verification popup could decide whether he/she trusts the executable code to work. The certificates are not expensive, virtually impossible to crack or counterfeit, easy to use and they provide a certain level of assertion about an executable code identity. However, they have several critical shortcomings. Specifically, the certificate asserts the identity of the software manufacturer and not the identity (or intent) of the executable code. For instance, a company that manufactures spying software will have its executable files signed and technically they are legitimate, although their intent from the “victim's” point of view is clearly malicious. Also, the process of verification of software manufacturer's identity by certificate issuing agencies is relatively simple so that virtually any ill-intended person or a business can receive it and disappear having a certificate that is valid for several years. Also, the certificate is just a small file (or two files) that can be copied or stolen and then used with malicious intent, while the manufacturer can potentially be held liable. This is particularly true for large companies, which have a sizable staff turnover and multiple departments using the same certificate. As a result, according to our data, the percentage of digitally signed executable files is actually going down, from about 3% in 2001 to 2.4% in 2002.
The most significant problem with all of the above-described solutions is that they either ineffective, impractical, offer protection only against known malicious executable code or are dependent on and limited by user's expertise. Therefore, the existing executable code control software may miss a new malicious executable code often just a simple variation of the old executable code. Therefore, there is a need for an effective, real-time system/method of protecting computer systems against known and unknown malicious executable code that does not require the user to continually download updates from a remote database or does not depend on the user's expertise and has a very low response threshold.